缓存更新策略
1.1 背景
- 引入缓存层后，除了享受缓存技术带来的并发性能的提升，还要做好缓存的维护工作，处理数据一致性问题，至于缓存的性能和数据一致性之间的权衡，不同的业务背景有不同的实现。
1.2 缓存更新策略
主动更新策略：
由我们自己在更新缓存时更新数据库
缓存和数据库整合为一个服务，调用者调用该服务即可
调用者只更新缓存，由其他线程异步的将缓存数据持久化到数据库中，保持最终一致，但是如果中间缓存宕机了，数据会丢失，可靠性不高。
我们选择手动编码的方式维护缓存数据和数据库的一致性。
在手动维护缓存数据的时候，有三个问题需要考虑：
删除缓存还是更新缓存？
初答：
- 分业务情况，如果对数据更新的粒度比较细，如改和删数据，操作缓存比较麻烦，我们就选择删除缓存
- 如果是增加数据，大多数情况下，都可以直接增加缓存
改进：
- 大多数情况下使用删除策略，因为删除是幂等（操作多次结果相同）的。
如何保证缓存和数据库操作的原子性？
初答：
- 责任链加回滚机制？
- 异常中断回滚机制？
改进：
单体应用可以将两个业务逻辑放在一个事务中实现，先操作数据库，后操作缓存
订阅Binlog（如Canal）：由 Canal 监听 MySQL 的 Binlog 变更，异步、自动地去删除/更新 Redis。这样业务代码解耦，且能保证数据库成功后缓存一定处理。还可以配合MQ，失败后，继续推送消息。
操作缓存和操作数据库的顺序？
初答：
- 先更新数据库，如果缓存不存在可以去查数据库，从而回写缓存